【レポート】AWS Summit Tokyo 2017: PlayStation™Network のフレンド機能「Friendlist」の AWS 移行事例 #AWSSummit

【レポート】AWS Summit Tokyo 2017: PlayStation™Network のフレンド機能「Friendlist」の AWS 移行事例 #AWSSummit

Clock Icon2017.06.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

aws-summit-tokyo-2017-longlogo

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリではDay3の導入事例トラックから「PlayStation™Network のフレンド機能「Friendlist」の AWS 移行事例 」をレポートしたいと思います。

セッション概要

当セッションの登壇者及び概要は以下の通りです。

スピーカー: 坂東 聖博 株式会社ソニー・インタラクティブエンタテインメント システム/ネットワークエンジニアリング&オペレーション部門 NPS運用部 システムオペレーション課セッション概要: 2006 年にサービスが開始された PlayStation™Network ですが、当初はもちろん全てのサービスがオンプレミス環境で稼働していました。現在でもまだ多くのサービスがオンプレミスで稼働していますが、本講演ではその中の 1 機能「Friendlist」について、MySQL から Amazon DynamoDB へのリプレイスを含む移行の手法について運用の観点からご紹介します。

セッションレポート

以下、セッションのレポートです。

本セッションの内容

  • PSNのFriend ListサービスをオンプレからAWSへ無停止で移行した
  • オンプレでの課題
  • AWSでどんな構成に
  • 何かおきたか
  • 教訓
  • 規模感

アジェンダ

  • Play Station Network
  • FriendListについて
  • オンプレ版の問題
  • AWS移行を決めるまで
  • AWS上のFriendListについて
  • まとめ

Play Station Network

  • Play Stationのためのオンラインサービス
  • Store
    • 会社のブラウザでゲームを買ったら、ウチの本体に来るとか
  • Plus
    • 月額500円でゲームができる
  • Now
    • 対戦、パーティーチャットなど

開発運用体制

  • 世界3拠点
  • San Diego
    • アカウントコマース
  • San Francisco
    • ストア、ソーシャル
  • 東京
    • ゲーム、ソーシャル

東京チームの担当

  • プロファイル
  • イベント/トーナメント
  • トロフィー
  • フレンド

PS4の発売からネットワークがより多く使われる傾向に

  • CDN配信量が増加
  • 毎年11-12月に大きく伸びる
  • トラフィック15Tbps
  • Monthly Active User 7000万人
  • 延週利用時間 6億時間
    • CloudFront使っている

FriendLlistについて

  • いわゆるお友達リスト
  • オンラインステータス、遊んでいるゲームなどを参照可能に
  • PS4で上限2000人
  • ブロックリスト、プライバシー設定
  • 様々な機能から参照される
  • トロフィーの取得状況など

Friend Listシステムへのアクセス

  • 基本的に他のサービスから間接的にアクセスされる
  • PSNのユーザエクスペリエンスに直結
  • かなりヘビーに使われる
    • 落ちた時ツイッターで死ねとか言われる

オンプレ版構成

  • LB+フロント4台で1セット
    • 24GB
    • httpd,tomcat,memcached
  • 更新系DB
    • CPU Xeon E5 2.6G x2
    • MySQL
    • 256G
    • ユーザ国別に3分割
    • 350GB 2億ユーザ
  • リード系を別途用意
  • リード系とフロントは上記3セットをDNSラウンドロビン

Friend Listの歩み

  • 2006/11 PS3発売 PSNの運用開始
  • 2010/03 高負荷のためフレンド機能をFriend Listとして別システムから独立
  • 2011/9 memcached導入
  • 2011/12 PSVita
  • 2013/9 フロントリプレイス
  • 2013/11 PS4発売 FriendListの上限が100から2000人に増大
  • 2014/4 DBリプレイス

Friend Listの問題点

  • スケールの難易度の高さ
  • メモリの上限256GBに限界
  • スケール速度の遅さ
  • 機材の物理調達だけで数ヶ月
  • 障害時の復旧の遅さ
  • レプリケーション

AWS移行の決断、経緯追加要件

  • 2016/2 トランザクション数とメモリ利用率が増大、リプレイスしたものの限界が見えてくる
  • 2017後半にTokyoオンプレ環境クローズの判断がされていた。リソース限界前にAWS環境に移行することを決定
  • PS4向けのサービスがAWSで稼働しており3000以上のインスタンスが稼働
  • PS4向けにDeploy Platformを構築済みだった

要求

  • ビジネス上
    • ダウンタイムを短く
    • 万一に備えてロールバック可能な
    • 将来のマルチリージョンを見越した構成に
  • デベロッパ
    • DBのプライマリキーを揃えたい(過去の経緯)
    • アプリは新規で作り直したい
  • オペレーション
    • DBはマネージドサービスを使いたい
    • 8月後の2016/10には終わらせたい 11/12月に負荷が上がる

移行プロジェクト

  • 2016/10まで
  • DBのPrimary Keyをconvertしながら
  • アプリは新規作成
  • この時点で2016/2

構成、ミドルウェア

  • フロント
    • ELB+EC2 c3.2xlarge apache
  • DynamoDB
    • ElastiCache Redis 2系
  • Auroraを使わないのはなぜ
    • いろいろ検討。マルチAZやリカバリタイムがポイント。
  • Redis採用の理由
    • 2系を採用
    • 将来の追加。ロック機能を使いたい

3ステップで移行

  • ダンプ、変換アプリ、データを配置
  • シンクロナイザ SNS+SQS
  • 最後切り替え

移行における前提

  • writeとreadがFQDNが別だった
  • ステータスファイルを参照
    • メンテナンスモード時はアクセスしない
  • 旧システムに更新時にSNSにPublishを追加
    • ↑ただ一つ追加した機能

切り替えの進行

  • 最初は全アクセスが旧システムに向いた状態
  • SNS Publish機能を有効化
    • 更新がSQSに貯まる
    • 14日以内にSQSの中身を処理せねばならない
  • DBからCSVでダンプを取る
    • その後に発生した更新はSQSにある
  • CSVをDynamoDBに格納
    • Primary Keyの変換もやる
  • シンクロナイザを使ってSQSのメッセージを新システムのDynamoDBに適用
    • Primary Keyの変換も実施
    • 1.5億件。空になるまで14時間かかった。開始したのが13日目でギリギリだった
  • トラブル
    • コンバータの変換が途中で止まったりした
      •  メモリを喰らい尽くす
      • スレッドがロックを取り合う
    • PK変換がうまくいかないユーザがいる
      • 実装を修正して再実施
    • サービスに影響を与えることなくリトライができる環境が重要だった
  • 参照系アクセスの一部を新アクセスに向ける
    • シンクロナイザのラグは数秒〜20秒
  • 全リードアクセスを新しい方へ向ける
    • Dynamoのキャパシティが超えていないか確認しつつ
    • Redisのスワップ使用量が増加
      • 切り戻してreserved memoryを確保、対策した
  • ラグが許されないサービスのみ残してほとんどのリードを向ける
  • Write系の切り替えのためメンテナンスモードに入れる
  • 旧サーバを停止
  • メンテナンスモードを解除
    • 更新アクセスも新サーバで処理開始

トラブル

  • なし(拍手)

結果

  • ロールバックせずに済んだ
  • Writeアクセスの切り替え
    • ダウンタイムは1H以下で済んだ
  • 切り替えは10/24に実施
    • 11/12月を前に無事移行が完了

規模

  • 350G 32億レコード
  • read 1500万/H
  • write 15k/h
  • 12/27 4.4億readアクセス/day達成
  • 49億アイテム 2つのテーブルに

AWSに移行してみて

  • スケールにおける課題が大幅な改善
  • DynamoDB ノーダウンタイム
    • ホットパティションが課題
  • Elasticache Redis
    • ほとんど落ちない
    • パラメータチューニングが課題

運用

  • DynanamoDBデータバックアップ
    • CloudFormation templateを使ってS3にダンプ

最後に

  • PSNは今後もAWSを使ってユーザエクスペリエンスを提供していく
  • 仲間募集中
    • Webサイト見てね

感想

オンラインサービスをオンプレで構築した話から始まって、規模拡大から課題が明らかになり、クラウドに移行を決断、ノンストップでスムーズにサービスを移行した様子が明快に解説されました。実践から語られる知見は重みがありますね。大変わかりやすくて面白かったです。

 

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.